1. The Field of the Invention
The present invention relates to detecting data corruption. More specifically, the present invention relates to systems, methods, and computer program products for detecting low-level data corruption when data is transferred between an application and a mass storage location.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., database management, electronic mail, and word processing) that prior to the advent of the computer system were performed manually.
A computer system typically includes an operating system, such as, for example, Unix or Microsoft® Windows®, which essentially manages the resources of the computer system, and various applications, such as word processing, spreadsheet, database software, presentation, email, etc. When user commands are entered into an application program, the application program often transfers execution of some commands to the operating system. For example, a “print” command entered into a word processor may ultimately result in the operating system performing at least some commands for queuing a document, formatting the document for output at a printer, sending the document to the printer, and so forth.
Users frequently issue Input/Output (“I/O”) commands, requesting that data either be written to a mass storage device (e.g., issuing a “save” command to store word processor or electronic mail data) or read from a mass storage device (e.g., issuing an “open” command to retrieve previously stored word processor or electronic mail data). When an operating system receives an I/O command from a user, the operating system generally coordinates the operation of a stack of “low-level” drivers that operate between the application and the mass storage device. For example, when data is transferred from an application to a mass storage device (a write command), the stack of low-level drivers may perform a series of operations to prepare the data for encoding on a magnetic disk. On the other hand, when data is transferred from a mass storage device to an application (a read command) the stack of low-level drivers performs essentially the inverse of these operations to prepare the data for use by the application.
Data blocks are often used to transfer data between an application and a mass storage device. A data block is a fixed number of bytes of data that is transferred as a single unit. An operating system can convert bulk data into one or more data blocks before data is written to a mass storage device. Conversely, the operating system can combine one or more data blocks into bulk data when data is read from the mass storage device.
As a data block passes through successive drivers included in the stack of low-level drivers, each driver may perform specifically designated operations on the data block. When a write operation occurs, a file system driver may process the data block for use by a particular file system (e.g., Network File System or File Allocation Table File System) and pass the data block to a class driver. The class driver may process the data block for use by a particular class of mass storage device (e.g. magnetic hard disk or CD-ROM) and pass the data block to a port driver. The port driver may process the block data for use by a particular storage standard (e.g., Small Computer System Interface or Integrated Drive Electronics) and pass the data block to a host bus adapter driver. The host bus adapter driver may encode the data block for storage (e.g., magnetic or optical encoding). When a read operation occurs, a data block is transferred through the drivers in essentially the reverse order. A host bus adapter driver decodes the data block for use by the particular storage standard, a port driver processes the data block for use by a particular class of mass storage device, a class driver processes the data block for use by particular file system, and a file system driver processes the data block for use by the operating system.
As the stack of low-level drivers processes a data block, there exists some potential for data contained within a data block to become corrupted. Data corruption can occur at virtually any low-level driver. Specifically, a driver may contain one or more programming errors that introduce erroneous data into the data block such that subsequent processing of the data block results in an error. For example, during a read command a host bus adapter driver may decode a data block improperly. Similarly, hardware (e.g., disks, disk arrays, hardware adapters, etc.) may corrupt a data block. Thus, an incorrect data block may be transferred up through the stack of drivers to the operating system and applications.
Data corruption caused by low-level drivers and/or hardware can result in application program errors and sometimes can result in failure of the application program or associated computer system. Identifying and correcting the cause of these types of failures often requires a high degree of technical expertise. Furthermore, application program errors caused by low-level data corruption may erroneously appear to a user to result from a defect in the application program or the underlying operating system and not from the low-level driver that actually caused the data corruption. For example, an error in an application program may occur as a result of a port driver causing a data block to be corrupted. However, a user may not be aware of the problem until the application program fails. Since the data corruption results in an error at the application program, the user may unknowingly assume that the application program caused the data corruption.
As such, some application programs implement error-checking modules to detect data corruption. This is beneficial as there is an increased chance of detecting data corruption before an error in an application program occurs. However, such error-checking modules provide limited, if any information about the cause of data corruption. There may be a number of low-level drivers between an application program and a mass storage device, any one of which can potentially cause data corruption. Thus, even if an error-checking module detects data corruption, there may be no way to determine that low-level drivers are causing the data corruption or determine which low-level driver is responsible for the data corruption. Furthermore, each individual application must perform its own separate error-checking.
Therefore, systems, methods, and computer program products for detecting low-level data corruption when data is transferred between an operating system and a mass storage device are desired.